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Abstract 

Compilers  for  polymorphic  languages  must  support  runtime  type 
analysis  over  arbitrary  source  language  types  for  coding  applica¬ 
tions  like  garbage  collection,  dynamic  linking,  pickling,  etc.  On 
the  other  hand,  compilers  are  increasingly  being  geared  to  gen¬ 
erate  type-safe  object  code.  Therefore,  it  is  important  to  support 
runtime  type  analysis  in  a  framework  that  generates  type  correct 
object  code.  In  this  paper  we  show  how  to  integrate  runtime  type 
analysis  over  all  types  of  a  higher  order  typed  source  language, 
including  quantified  types,  into  a  system  that  can  propagate  type 
information  through  all  compilation  phases. 
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1  Introduction 

Modern  programming  paradigms  increasingly  rely  on  applica¬ 
tions  requiring  runtime  type  analysis,  like  dynamic  linking, 
garbage  collection,  and  pickling.  For  example,  Java  adopts  dy¬ 
namic  linking  and  garbage  collection  as  central  features.  Dis¬ 
tributed  programming  requires  that  code  and  data  on  one  ma¬ 
chine  be  pickled  for  transmission  to  a  different  machine.  In  a 
polymorphic  language,  the  compiler  must  rely  on  runtime  type 
information  to  implement  these  applications.  Furthermore,  these 
applications  may  operate  on  arbitrary  runtime  values;  therefore, 
the  compiler  must  support  the  analysis  of  the  types  of  arbitrary 
source  language  terms,  which  we  refer  to  as  fully  reflexive  type 
analysis. 

On  the  other  hand,  generation  of  certified  code  [11]  is  ap¬ 
pealing  for  a  number  of  reasons.  We  no  longer  need  to  trust 
the  correctness  of  the  compiler;  instead,  we  can  verify  the  cor¬ 
rectness  of  the  generated  code.  Checking  the  correctness  of  a 
compiler-generated  proof  (of  a  program  property)  is  much  easier 
than  proving  the  correctness  of  the  compiler.  Moreover,  since  we 
can  verify  code  before  executing  it,  we  are  no  longer  restricted  to 
executing  code  generated  only  by  trusted  compilers. 

*This  research  was  sponsored  in  part  by  the  Defense  Advanced  Research 
Projects  Agency  ISO  under  the  title  “Scaling  Proof-Carrying  Code  to  Production 
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tract  No.  F30602-99-1-0519,  and  in  part  by  NSF  Grants  CCR-9633390  and  CCR- 
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A  necessary  step  in  building  a  certifying  compiler  is  to  have 
the  compiler  generate  code  that  can  be  type-checked  before  exe¬ 
cution.  The  type  system  ensures  that  the  code  accesses  only  the 
provided  resources,  makes  legal  function  calls,  etc.  Therefore,  it 
is  important  to  support  runtime  type  analysis  (over  types  of  ar¬ 
bitrary  source  language  terms)  in  a  framework  that  can  generate 
type-correct  object  code.  Crary  et  al.  [3]  proposed  a  framework 
that  can  propagate  types  through  all  phases  of  compilation.  The 
main  idea  is  to  construct  and  pass  terms  representing  types,  in¬ 
stead  of  the  types  themselves,  at  runtime.  This  allows  the  use  of 
existing  term  operations  to  process  runtime  type  information.  Se¬ 
mantically,  singleton  types  are  used  to  connect  a  type  to  its  repre¬ 
sentation.  From  an  implementor’s  point  of  view,  this  framework 
(hereafter  referred  to  as  the  CWM  framework)  seems  to  sim¬ 
plify  some  phases  in  a  type-preserving  compiler;  most  notably, 
typed  closure  conversion  [9],  However,  the  framework  proposed 
in  [3]  supports  only  the  analysis  of  types  with  no  binding  struc¬ 
ture;  specifically,  it  does  not  support  the  analysis  of  polymorphic 
or  recursive  types.  This  limits  the  applicability  of  their  system 
since  most  type-analyzing  applications  must  deal  with  recursive 
objects  or  polymorphic  code  blocks. 

In  this  paper,  we  extend  the  CWM  framework  and  encode  a 
language  supporting  fully  reflexive  type  analysis  into  this  frame¬ 
work.  The  language  is  based  on  our  previous  work  [13];  accord¬ 
ingly,  it  introduces  polymorphism  at  the  kind  level  to  handle  the 
analysis  of  quantified  types.  This  requires  a  significant  extension 
of  the  CWM  framework.  Moreover,  even  with  kind  polymor¬ 
phism,  recursive  types  pose  a  problem,  which  requires  constrain¬ 
ing  the  analysis  of  recursive  types  in  the  source  language,  and 
introducing  unconventional  fold  and  unfold  constructs  in  the  tar¬ 
get  language. 

The  rest  of  the  paper  is  organized  as  follows.  We  give  an 
overview  of  intensional  type  analysis  in  Section  2.  We  present 
the  source  language  Xf +  in  Section  3.  Section  4  shows  the  tar¬ 
get  language  A^  that  extends  the  CWM  framework.  We  offer  a 
translation  from  Ap+  to  in  Section  5. 

2  Intensional  type  analysis 

Harper  and  Morrisett  [7]  proposed  intensional  type  analysis  and 
presented  a  type-theoretic  framework  for  expressing  computa¬ 
tions  that  analyze  types  at  runtime.  They  introduced  two  oper¬ 
ators  for  explicit  type  analysis:  typecase  for  the  term  level  and 
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Typerec  for  the  type  level.  For  example,  a  polymorphic  subscript 
function  for  arrays  might  be  written  as  the  following  pseudo¬ 
code: 

sub  =  Aa.  typecase  a  of 
int  =£■  intsub 
real  =>  realsub 
/3  =t-  boxedsub  \(3\ 

Here  sub  analyzes  the  type  a  of  the  array  elements  and  returns 
the  appropriate  subscript  function.  We  assume  that  arrays  of  type 
int  and  real  have  specialized  representations,  say  intarray  and 
realarray,  and  therefore  have  specialized  subscript  functions;  all 
other  arrays  use  the  default  (boxed)  representation. 

Typing  this  subscript  function  is  more  interesting,  because  it 
must  have  all  of  the  types  intarray  — >  int  — >  int,  realarray  — > 
int  — >  real,  and  boxedarray  (a)  — >  int  — >  a  for  a  other  than  int 
and  real.  To  assign  a  type  to  the  subscript  function,  we  need  a 
construct  at  the  type  level  that  parallels  the  typecase  analysis  at 
the  term  level.  The  subscript  operation  would  then  be  typed  as 

sub  :  Vq.  Array  (a)  — >  int  — >  a 
where  Array  =  Aa.  Typecase  a  of 

int  intarray 
real  =>■  realarray 
/3  =>  boxedarray  /3 

The  Typecase  construct  in  the  above  example  is  a  special  case  of 
the  Typerec  construct  in  [7],  which  supports  primitive  recursion 
over  types. 

3  The  source  language  Af + 

To  illustrate  our  ideas,  we  define  the  Af +  calculus  with  syntax 
shown  in  Figures  1  and  2.  The  static  semantics  of  Af +  uses  the 
following  three  environments: 

sort  environment  £  ::=  e  \  £,x 

kind  environment  A  ::=  e  \  A,  a:  k 

type  environment  T  ::=  e\Y,x:t 

It  can  be  shown  that  the  formation  rules  in  Figure  3  enforce  the 
requirement  that  the  environments  are  well-formed,  and  more¬ 
over,  all  inferred  types  and  kinds  are  also  well-formed.  Thus,  in 
the  type  formation  rule  £;A  h  r  :  k,  we  have  that  £  h  A  and 
£  h  ft.  In  the  term  formation  rule  £ ;  A;  T  h  e  :  r,  we  have  that 
£  h  A  and  £\  A  h  T  and  £ ;  A  h  r  :  £1.  Reduction  in  the  type 
language  is  defined  according  to  the  rules  in  Figure  4.  The  re¬ 
duction  rules  for  the  term  level  type  analysis  construct  typecase 
can  be  found  in  Figure  5. 

The  language  Af +  extends  the  language  A f  proposed  in  [13] 
with  recursive  types,  and  some  additional  constructs  for  analyz¬ 
ing  recursive  types.  This  section  only  gives  an  overview  of  the 
language,  the  reader  may  refer  to  [13]  for  more  details. 

In  the  impredicative  calculus  the  polymorphic  types  Va : 
k.  t  can  be  viewed  as  generated  by  an  infinite  set  of  type  con¬ 
structors  VK  of  kind  (k  — >  ft)  —>  £1,  one  for  each  kind  k.  The 
type  Va :  k.  t  is  then  represented  as  VK  (Aa :  k.  t).  The  kinds  of 


(kinds)  k  ::=  £1  \  k  — >  k'  \  \  I  Vx-  /t 

(types)  t  ::=  int  |  — »  |  V  |  V+  |  p  |  Place 

a  |  Ax-  t  |  Aa  :k.t  |  r  [k]  |  tt' 

Typerec  r  of  (rint;  r rv;  r^) 

(values)  v  ::=  i  \  A+x-f  |  Aa:K.v  \  \x:r.e  \  fi xx:t.v 

fold[r]  v 

(terms)  e  ::=  v  \  x  \  e  [ft]+  |  e  [r]  |  ee' 
fold[r]  e  |  unfold[r]  e 
typecase[r]  r'  of  (eint;  e^;  ev;  e^;  eM) 

Figure  1:  Syntax  of  the  Af +  language 


T  t'  =  ((— »)  t)  T 
Va\K.T  =  (V[/t])  (Xa-.K.r) 
v+  X-  T  =  V  (Ax-  t) 

Figure  2:  Syntactic  sugar  for  Af +  types 


constructors  that  can  generate  types  of  kind  Q  would  then  be 


int 

£1 

— » 

£1  —>  £1  £1 

Vn 

(£1  — ¥  £1)  — ¥  £l 

VK 

(k  — >  12)  — >  £1 

We  can  avoid  the  infinite  number  of  VK  constructors  by  defining 
a  single  constructor  V  of  polymorphic  kind  Vx-  (x  — *  fi)  — »  12 
and  then  instantiating  it  to  a  specific  kind  before  forming  poly¬ 
morphic  types.  More  importantly,  this  technique  also  removes 
the  negative  occurrences  of  £1  from  the  kind  of  the  argument 
of  some  constructors,  e.g.  Vn;  these  occurrences  make  £1  non- 
inductive,  so  that  defining  a  Typerec-like  “iterator”  over  £1  would 
break  the  crucial  strong  normalization  property  of  the  type  lan¬ 
guage.  Hence  in  our  Af +  calculus  we  extend  Fu  with  variable 
and  polymorphic  kinds  (x  and  V\-  k)  and  add  a  type  constant  V 
of  kind  Vx-  (x  ~ >  fi)  — >  £1  to  the  type  language.  The  polymor¬ 
phic  type  Va  :k.t  is  now  represented  as  V  [k]  (Aa  :k.t). 

While  analyzing  a  polymorphic  type  V  [k]  r,  the  kind  k  must 
be  held  abstract  to  ensure  termination  of  the  analysis  [13].  There¬ 
fore,  the  Typerec  operator  needs  a  kind  abstraction  in  the  branch 
corresponding  to  the  V  constructor.  We  provide  kind  abstraction 
Ax-  t  and  kind  application  r  [tt]  at  the  type  level.  The  formation 
rules  for  these  constructs,  excerpted  front  Figure  3,  are 

£  V  A  £,  x;  A  h  r  :  k  £;AYt:Vx-k  £  V  k' 
£;Ah  Ax-  r  :  Vx-  k  £;Afr  [tt']  :  tt{tt'/x} 

Similarly,  at  the  term  level,  the  typecase  operator  must  analyze 
polymorphic  types  where  the  quantified  type  variable  may  be  of 
an  arbitrary  kind.  To  avoid  the  necessity  of  analyzing  kinds,  the 
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|  Kind  formation  £  \~  k  \ 

X  £  £  £  \-  k,  £  I -  k!  £.  \  ■  />• 

£  h  fi  f  h  x  £1 -  *!  fhVx./t 

Kind  environment  formation  f  h  A 

f  h  A  £•  K 
£  h  £  £  b  A,  a :  k 

Type  formation  £ ;  A  h  t  :  k 
£  I-  A 

£;  A  h  int  :  fi 
£;  A  h  (— *)  :  fi  — *  fi  — >  fi 
£;  A  h  V  :  Vx-  (x  -►  fi)  -►  fi 

£ ;  A  h  V+  :  (Vx-  fi)  -»  fi 

£;Ah  fi  :  (0  — s-  S7)  — s-  £7 
£;  A  h  Place  :  fi  — >  fi 

£  h  A  a :  k  in  A 
£;Ah«  :  K 

£h  A  £,x;Ahr:tv  £;  A  h  r  :  Vx- «  £  \~  k' 
£;AI-Ax-t  :  Vx-  «  £;A(-t[k/]  :  k{k'/x} 

£;  A,  a :  k  h  t  :  «/ 

£;AhAa:K.r  :  /t  — ►  k' 

£;AI -  t  :  Kr —*  K  £;A\~t':k' 

£;  A  h  t  t'  :  K 

£■  A  h  r  :  fi 
£;  A  h  Tint  :  fi 

£ ;  A  I-  r_  :  fi^fi— »fi— >fi^fi 

£;  A  h  tv  :  vx.  (x  ^  fi)  ^  (x  ^  fi)  ^  fi 
£;AhV:  (Vx- fi)  — >  (Vx- fi)  — >  fi 

£;  A  I-  Typerec  r  of  (nnt;  r_;  ry;  ry+)  :  fi 

Type  environment  formation  £;  A  h  T 

£  h  A  £;  A  h  T  £;  A  h  r  :  fi 
£;  A  h  £  £;  A  h  F,  *:t 


Term  formation  £;  A;  T  h  e  :  r 

£;  A;  T  h  e  :  r  £;  A  h  r  t  :  fi 
£;  A;T  I -  e  :  t' 

£;  A  h  T 
£;  A;T  h  i  :  int 

£;  A  h  T  xirinT  £,x;  A;T  l~  v  :  r 
£;  A;T  h  x  :  t  £;  A;  T  h  A+X-  v  :  V+x.  r 

£;  A,a:/t;F  h  v  :  r  £;  A;  F,  x :  r  P  e  :  r' 

£;  A;  T  h  Aa :  k.  v  :  Va :  k.  r  £;  A;T  h  Ar:r.e  :  r  — >  t' 

£;  A;  T  I -  e  :  V+r  £hs 
£;  A;  T  h  e  [k]+  :  r  [«] 

£;  A;  T  h  e  :  V  [k]  r  £;  A  h  t'  :  k 
£;  A;  T  h  e  [ t  ]  :  r  t' 

£;  A;T  h  e  :  r'  ->  r  £;A;rhe'  :  r' 

£;  A;  T  I—  ee'  :  r 

£;  A;  F,  x:t  h  v  :  r 

t  =  V  xi  •  •  •  Xn- Vai  :ki  - . .  am:«m. n  — >  T2 
n  >  0,m  >  0 

£;  A;  T  h  fixx:r.  v  :  r 

£;Ahr:fi^ii  £;  A;  T  h  e  :  r  (pr) 

£;  A;  T  h  fold[r]  e  :  pr 

£;Ahr  :  fi^fi  £;A;TI-e:pr 
£;  A;  T  h  unfold[r]  e  :  r  (pr) 

£;  A  h  r  :  fi  — >  fi 
£;Ahr'  :  fi 
£;  A;  T  h  eint  :  t  int 

£;  A;  T  h  e~,  :  Va: fi.  Va' : fi.  r  (a  ->  a') 
£;A;Fhey  :  V+X-  Va  :x  — >  fi-  r  (V  [x]  a) 

£;  A;  T  P  ey  :  Va:  (V*.  fi).  r  (V+a) 

£;A;TI-eM  :  Va:fi  ^  fi.r(pa) 

£;  A;T  h  typecase[r]  r'  of  (eint;  e^;  ey;  ey;  eM)  :  tt' 


Figure  3:  Formation  rules  of  A^+ 
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Type  reduction  £:  A  ;  •  n  r-j  :  k 


£,  x;  A  b  r  :  K  £  b  k' 

£;  A  b  (A x-t)  \k'}  t{k ' /x}  ■  k{k'/x} 


^A.aiK’hr  :  k  £;Ab  t'  :  k' 

£;  A  b  (Aa:«/.  r)  r;  t{V/q:}  :  k 

£;Abr  :  a  £  ftv(r) 

£;  A  b  A tt:c.Ttt-wT  :  K  — >  «/ 

£ ;  A  b  Typerec  int  of  (Tint;  t.^;  tv;  Tyf)  :  SI 

f;Ab  Typerec  int  of  (Tint;  7v;  Tyf)  Tint  :  fl 

5;  A  b  Typerec  n  of  (Tint;  t tv;  t^)  t(  :  SI 

5;  A  b  Typerec  t2  of  (Tint;  t_;  tv;  t^)  t2  :  SI 

£ ;  A  b  Typerec  ((-»)  ti  t2)  of  (Tint;  t^;  tv;  tv+) 

T-^  Tl  T2  t(  t2  :  ft 

£;  A  b  Typerec  (PlaceT)  of  (Tint;  t.^;  tv;  tv+)  :  ft 
£;  A  b  Typerec  (PlaceT)  of  (Tint;  tv;  t^t)  t  :  ft 


£;Ab  t:Vx'.k  X^fkv(r) 

£;  A  b  Ax-  t  [x]  t  :  Vx*.  re 

£;  A,  a:  rt' b  Typerec  (to)  of  (Tint;  t.^;  tv;  t^)  t'  :  SI 

£;  A  b  Typerec  (V  [«/]  t)  of  (Tint;  t^;  tv;  t^) 
w  [re/]  t  (Aa :  «/.  t')  :  ft 

£,  X;  A  b  Typerec  (t  [x])  of  (Tint;  t^;  tv;  t^)  t'  :  ft 
£;  A  b  Typerec  (V+  t)  of  (-Tint;  t-.;  tv;  t^)  t^  t  (Ax-  t')  :  SI 

£;  A,  a:  SI  b  Typerec  (t  (Place a))  of  (Tint;  t_»;  tv;  tv+)  t'  :  ft 
£;  A  b  Typerec  ((jt)  of  (-nnt;  T->;  tv;  t^)  p  (AoiSIt')  :  ft 


Figure  4:  Selected  Af +  type  reduction  rules 


typecase  must  bind  a  kind  variable  to  the  kind  of  the  quantified 
type  variable.  For  that  purpose  we  introduce  kind  abstraction 
A  x-  v  and  kind  application  e  [ft]  at  the  term  level.  To  assign 
types  to  these  new  constructs  at  the  term  level,  we  need  a  type 
level  construct  V  X- T  that  binds  the  kind  variable  x  in  the  type 
t.  The  formation  rules  are  shown  below. 

f,X;A;rbv:T  £;  A;T  b  e  :  V+X-t  £  b  ft 

£;  A;  T  b  A+x-  v  :  V+x.T  £;  A;  T  b  e  [ft]+  :  t{k/x} 

Furthermore,  since  our  goal  is  fully  reflexive  type  analysis,  we 
need  to  analyze  kind-polymorphic  types  as  well.  As  with  poly¬ 
morphic  types,  we  can  represent  the  type  V  x-  t  as  the  applica¬ 
tion  of  a  type  constructor  V  of  kind  (Vx-  ft)  —>  ft  to  the  type 
A  x-t. 

The  Typerec  operator  is  used  for  type  analysis  at  the  type 
level.  In  fact,  it  allows  primitive  recursion  at  the  type  level.  It 
operates  on  types  of  kind  ft  and  returns  a  type  of  kind  SI  (Fig¬ 
ure  4).  Depending  on  the  head  constructor  of  the  type  being  an¬ 
alyzed,  Typerec  chooses  one  of  the  branches.  At  the  int  type,  it 
returns  the  Tint  branch.  At  the  function  type  t  — >  t',  it  applies 
the  T— >  branch  to  the  components  t  and  t\  and  to  the  results  of 
recursively  processing  t  and  t  . 

Typerec  (t  — >  t)  of  (Tint;  r-»;  tv;  tv+) 

T— ,  t  t'  (Typerec  t  of  (Tint;  t_>;  tv;  t^)) 

(Typerec  t'  of  (Tint;  t_^;  tv;  tv+)) 

When  analyzing  a  polymotphic  type,  the  reduction  rule  is 

Typerec  (Voik'.t)  of  (Tint;  t_^;  tv;  tv+)  ~t- 

tv  [ft']  (A ct.k'.t)  (A a:n' .  Typerec  t  of  (Tint;  t_>;  7v;  tj-)) 


Since  tv  must  be  parametric  in  the  kind  k'  (to  ensure  termination, 
there  are  no  facilities  for  kind  analysis  in  the  language  [13]),  it 
can  only  apply  its  second  and  third  arguments  to  locally  intro¬ 
duced  type  variables  of  variable  kind,  instantiated  to  k1  during 
the  analysis.  We  believe  this  restriction,  which  is  crucial  for  pre¬ 
serving  strong  normalization  of  the  type  language,  is  quite  rea¬ 
sonable  in  practice.  For  instance  tv  can  yield  a  quantified  type 
based  on  the  result  of  the  analysis. 

The  reduction  rule  for  analyzing  a  kind-polymorphic  type  is 

Typerec  (V  X-  t)  of  (nnt;  t_;  tv;  t^) 

V  (A*-  T)  (AA-  Typerec  t  of  (Tint;  r-;  tv;  tv f)) 

The  V+-branch  of  Typerec  gets  as  arguments  the  body  of  the 
quantified  type  and  a  kind  function  encapsulating  the  result  of 
the  analysis  on  the  body  of  the  quantified  type. 

The  treatment  of  recursive  types  is  similar  to  that  in  the  lan¬ 
guage  A^  of  [13],  but  simplified.  They  are  formed  using  the  p 
constructor  of  kind  (ft  —>  ft)  —>  ft.  Following  ideas  due  to 
Fegaras  and  Sheard  [6],  for  the  analysis  of  recursive  types  we  in¬ 
troduce  a  unary  constructor  Place  of  kind  ft  — ♦  ft,  which  is  not 
intended  for  use  by  the  programmer;  the  term  language  provides 
no  constructors  to  create  a  non-variable  object  of  type  PlaceT 
for  any  t. 

The  simpler  kind  language  of  Xf+  (in  comparison  with  A^ ) 
comes  at  the  price  of  restricting  the  result  of  the  analysis  of  re¬ 
cursive  types  by  a  Typerec  to  always  be  a  recursive  type.  Thus 
we  avoid  a  problem  arising  when  the  analysis  of  a  recursive  type 
yields  a  result  unrelated  to  the  analysis  of  its  unfolding,  described 
further  in  Section  4.4. 

Since  the  argument  of  the  p  constructor  has  a  negative  oc¬ 
currence  of  the  kind  ft,  this  case  must  be  handled  differently. 
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typecase[r]  int  of  (eint;  e^;  ev;  ey+;  e^)  ~>eint 

typecase[r]  (n— >r2)  of  (eint;  e^;  ev;  e^;  eM)  [ti][t2] 

typecase[r]  (V  [k]  t')  of  e^;  ev;  e^g;  eM)  ~>ev  [«]  [t'] 

typecase[r]  (V  t')  of  (eint;  e-,\  ev;  e^;  eM)  [r'] 

typecase[r]  (pr)  of  (eint;  e — ev;  ey+;  eM)  [r'] 

typecase[r]  (Placer')  of  (eint;  e^;  ev;  e^g;  e/2)~» 

typecase[r]  (Placer')  of  (eint;  e^;  ev;  e^g;  eM) 

Figure  5:  Selected  term  reduction  rules  of  Af + 


Typerec  does  not  act  as  an  iterator  for  the  p  constructor.  In¬ 
stead,  it  analyzes  the  body  of  the  type  with  the  /.(-bound  variable 
protected  under  the  Place  constructor.  Since  Place  is  the  right 
inverse  of  Typerec  (Figure  4),  the  analysis  terminates  when  it 
reaches  such  a  type  variable. 

Typerec  (pr)  of  (rint;  r^;  rv;  Ty g) 

p  (Aa:fi.  Typerec  (r  (Place a))  of(ri„t;  T-,;  7v;  t*)) 

In  essence,  we  have  made  the  p  constructor  transparent  to  the 
analysis.  Operationally,  the  number  of  nested  p  constructors  in 
the  type  analyzed  by  a  Typerec  strictly  decreases  at  every  reduc¬ 
tion  involving  p,  ensuring  termination  after  a  finite  number  of 
steps. 

The  term  expressions  are  mostly  standard.  We  use  the  stan¬ 
dard  fold  and  unfold  constructs  to  implement  the  isomorphism 
between  a  recursive  type  and  its  unfolding.  Type  analysis  at  the 
term  level  is  performed  using  the  typecase  operator.  Since  the 
term  level  includes  a  fixed-point  operator,  typecase  is  not  itera¬ 
tive;  it  inspects  a  given  type  r'  and  passes  its  constituents  to  the 
corresponding  branch.  The  reduction  rules  for  typecase  are  in 
Figure  5. 

Existential  types  can  be  handled  similarly  to  polymorphic 
types.  We  define  a  type  constructor  3  of  kind  Vx-  (x  ~ > 
fi)  — >  fi.  The  existential  type  3 a  :  k.  t  is  then  equivalent  to 
3  [tc]  (Aa  :  k.  t).  Typerec  and  typecase  are  augmented  with  rg 
and  eg  branches  respectively.  The  reduction  rules  are  exactly 
analogous  to  those  for  the  polymorphic  type. 

To  illustrate  the  type  level  analysis  we  will  use  the  Typerec 
operator  to  define  the  class  of  types  admitting  equality  com¬ 
parisons.  We  will  extend  the  example  in  [7]  to  handle  quan¬ 
tified  types.  The  type  operator  Eq  :  fi  ^  fi,  defined  below, 
maps  function  and  polymorphic  types  to  the  type  Void.  (Here 
Void  =  Va  :  fi.  a  is  a  type  with  no  values).  To  make  the  exam¬ 
ple  more  realistic,  we  extend  the  language  with  a  product  type 
constructor  (x )  of  the  same  kind  as  (— »).  The  type  analysis  con¬ 
structs  operate  on  the  x  constructor  in  a  manner  similar  to  the 
— »  constructor.  For  ease  of  presentation  we  use  ML-style  pattern 


fixtoString:  Va :  fi.  a  — »  string. 

=  A  a :  fi. 

typecase[A7:fi.  7  — >  string]  a  of 
int  =7  intToString 
string  =7  Aa: :  string,  x 

x  =7  A/3i  :fi.  A/32  :  fi.  \x-.pi  x  /32. 

toString  [/3 1]  (x.l)  ~  toString  [/32]  (x.2) 

— »  =7  A/3i :  fi .  A/32  :  fi .  Aa: :  /3i  — >  /32 .  “ function " 

V  =7  A+x-  A/3 :  x  — >  fi-  Ax :  V  [x]  /3.  “ polymorphic " 

V  =7  A/3:Vx-  fi.  Aat:V  /3.  “kind polymorphic" 
p  =7  A/3: fi  — +  fi.  Ax:  p  /?. 

toString  [/3  (p  /3)]  (unfold[/3]  x) 

Figure  6:  The  function  toString 


matching  syntax  to  define  a  type  involving  Typerec:  Instead  of 

t  =  Aa:fi.  Typerec  a  of  (rint;  tv;  t +) 
where  t_>  =  Aai :  fi.  Aa2  :  fi.  Aa'x :  k.  Xa'2  :  k.  tL> 
rv  =  Ay.  Aa :  x  — >  fi-  Aa' :  x  ~ >  K-  Tv 
V  =  Aa :  (Vx-  O)-  Aa' :  (Vx-  k).  t fg 

we  write 

t  (int)  =  rint 

t  (ai  — >  a2)  =  r^{t(ai),t(a2)/a'1,a2} 

t  (V  [x]  a)  =  rv{Aai:x-t(aar)/a'} 

t  (V+  a)  =  ry+{Ax-t(a[x])/a'} 

In  this  syntax  the  Eq  type  operator  is  defined  as: 

Eq  (int)  =  int 

Eq  (ai  x  a2)  =  Eq  (ai)  x  Eq  (a2) 

Eq  (ai  — >  a2)  =  Void 
Eq  (V  [x]  a)  =  Void 
Eq  (V+  a)  =  Void 

Eq(pa)  =  p  (Aai  :fi.  Eq  (a  (Placeai))) 

where  the  last  line  of  the  definition  is  not  under  programmer  con¬ 
trol. 

As  an  example  of  the  term  level  analysis  in  Af +,  consider 
the  function  toString  shown  in  Figure  6.  This  function  uses  the 
type  of  a  value  to  produce  its  string  representation;  we  assume 
having  a  nullary  type  constructor  string  in  the  language.  The 
primitive  function  intToString  converts  an  integer  to  its  string 
representation,  and  use  '  to  denote  string  concatenation. 

The  language  Af +  has  the  following  properties,  with  proofs 
similar  to  those  for  the  language  Af  in  [13]. 

Proposition  3.1  (Strong  Normalization)  Reduction  of  well- 
formed  types  is  strongly  normalizing. 

Proposition  3.2  (Confluence)  Reduction  of  well-formed  types 
is  confluent. 

Proposition  3.3  (Type  Safety)  If\-  e :  r,  then  either  e  is  a  value, 
or  there  exists  a  term  e  such  that  e  e  and  he  :t, 
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3.1  Type  analysis  in  Af+ 

In  our  previous  work  [13],  we  proposed  the  language  Xf  which 
supports  the  analysis  of  recursive  types  without  any  restrictions. 
However,  the  resulting  language  gets  complex  and  the  translation 
into  a  CWM  framework  is  not  clear.  Therefore,  type  analysis  in 
Xf +  is  restricted  in  two  ways.  First,  the  Typerec  operator  must 
return  a  type  of  kind  Q.  Second,  the  result  of  analyzing  a  recur¬ 
sive  type  is  always  a  recursive  type.  We  believe  that  these  restric¬ 
tions  do  not  reduce  significantly  the  usefulness  of  the  language 
in  practice. 

The  main  purpose  of  Typerec  is  to  provide  types  to  typecase 
terms;  every  branch  of  the  Typerec  types  the  corresponding 
branch  of  the  typecase.  Since  the  type  of  a  term  is  always  of 
kind  Q,  the  result  of  the  Typerec  must  also  be  of  kind  H.  Thus, 
in  practice,  a  Typerec  will  be  employed  to  form  types  of  kind  O. 

In  some  cases  a  Typerec  is  used  to  enforce  typing 
constraints — for  example,  in  the  case  of  polymorphic  equality 
above,  a  Typerec  was  used  to  express  the  constraint  that  the  set 
of  equality  types  does  not  include  function  or  polymorphic  types. 
In  these  cases  the  Typerec  merely  verifies  that  an  input  type  is 
well-formed,  while  preserving  its  structure.  This  means  that  the 
Typerec  will  map  a  recursive  type  into  a  recursive  type. 

Other  applications  of  type  analysis  also  follow  this  pattern. 
Consider  a  copying  garbage  collector  [14],  Its  copying  function 
would  use  a  Typerec  to  express  that  data  from  a  particular  region 
has  been  copied  into  a  different  region.  Since  the  structure  of  the 
data  remains  the  same  after  being  copied,  a  recursive  type  would 
still  be  mapped  into  a  recursive  type.  The  same  holds  true  while 
flattening  tuples.  Flattening  involves  traversing  the  input  type 
tree,  and  converting  every  tuple  into  the  corresponding  flattened 
type;  therefore,  the  structure  of  the  input  type  is  preserved. 

Our  language  allows  the  analysis  of  recursive  types  within 
both  the  term  language  and  the  type  language,  but  combining 
them  is  subject  to  severe  limitations.  For  instance,  one  can  write 
a  polymorphic  printer  that  analyses  types  at  runtime,  and  one 
can  write  a  type  operator,  like  Eq,  to  enforce  invariants  at  the 
type  level.  However,  it  is  not  possible  to  write  a  polymorphic 
equality  function  that  analyzes  types  at  runtime  and  has  the  type 
Vq  :  fi.  Eq  a  — +  Eq  a  — >  bool.  The  reason  is  that  when  the  recur¬ 
sive  type  Eq  (pr)  is  unfolded,  the  result  is  Eq  (r  (Place  (pr))). 
The  equality  function  must  now  analyze  the  type  r  (Place  (pr)), 
which  requires  it  to  analyze  a  Place  type.  However,  no  useful 
term  can  be  provided  in  the  corresponding  branch  of  typecase. 
This  problem  does  not  affect  the  p-free  segment  of  the  language 
and  its  translation. 

4  The  target  language  A^ 

Figure  7  shows  the  syntax  of  the  XR  language,  the  target  of  our 
translation,  which  reflects  type  information  at  the  term  level  in 
preparation  for  type  erasure.  To  make  the  presentation  simpler, 
we  will  describe  many  of  the  features  of  XR  in  the  context  of  the 
translation  from  Xf +. 


(kinds)  k  ::=  Q  |  T  |  ft  — >  k'  \  x  I  Vx- ft 

(types)  t  ::=  int  |  — »  |  V  |  V+  |  p  j  PI  |  R 

|  Tim  I  T_  I  Tv  I  Tyf  I  I  Tpi  I  Tr 

a  |  Ax- t  |  r  [ft]  |  Xa\K.T  \  tt' 

Tagrec  r  of  (rint;  r^;  rv;  rv+;  rR) 

(values)  v  ::=  i  |  A+x-  v  \  Acc.k.v  \  Xx-.r.e  |  fi xx-.t.v 

fold[r]  v 

Rint  I  R->  |  [r]  I  [r]  V 

R^[r]v[r']  |  R^  [r]  if  [r']  v' 

Rv  |  Rv[ft]+  |  Rv[ftf[r]  |  Rv[ft]+[r][r'] 
RvM+[r][r> 

R^  |  R yf[r]  I  Ryf  [t]  v 
RM  I  Rf  [r]  I  Rf.  [t]  v 
R Pi  |  RPi  [t]  |  Rpi  [t]  v 
Rr  I  Rj?  M  I  Rfl  M  v 

(terms)  e  ::=  v  \  x  \  e  [«]+  |  e  [r]  |  ee! 

fold[r]  e  |  unfold[r]  e 

|  repcase[r]  e  of  (eint;  e^;  ev;  e^;  eR\  eR\  epi) 

Figure  7:  Syntax  of  the  XR  language 


4.1  The  analyzable  components  in  XR 

In  A|j,  the  type  calculus  is  split  into  types  and  tags:  While  types 
classify  terms,  tags  are  used  for  analysis.  We  extend  the  kind 
language  to  distinguish  between  the  two:  Kind  S7  is  assigned  to 
types,  while  kind  T  is  assigned  to  tags.  For  every  constructor 
yielding  a  type  of  kind  fl  we  have  a  corresponding  constructor 
that  generates  a  tag  of  kind  T ;  for  example,  Tmt  corresponds  to 
int  and  T_,  corresponds  to  The  type  analysis  construct  at  the 
type  level  is  Tagrec,  which  operates  only  on  tags. 

At  the  term  level,  we  add  representations  for  tags.  The  term 
level  operator  (now  called  repcase)  analyzes  these  representa¬ 
tions.  All  the  primitive  tags  have  corresponding  term  level  rep¬ 
resentations;  for  example,  T]nt  is  represented  by  R|nt.  Given  any 
tag,  the  corresponding  term  representation  can  be  constructed  in¬ 
ductively. 

4.2  Typing  term  representations 

The  type  calculus  in  A^  includes  a  unary  type  constructor  R  of 
kind  T  — >  n  to  type  the  term  level  representations.  Given  a 
tag  r  (of  kind  T ),  the  term  representation  of  r  has  the  type  R  r. 
For  example,  Ri„t  has  the  type  R  Tint-  Semantically,  Rr  is  in¬ 
terpreted  as  a  singleton  type  that  is  inhabited  only  by  the  term 
representation  of  r  [3]. 

The  functionality  of  R  is  generalized  at  higher  kinds  by  RK, 
a  type  function  of  kind  k  — >  Q,  such  that  RK  r  is  the  type  of  the 
term  representation  for  type  r  of  kind  k.  For  instance,  if  the  tag  r 
is  of  a  function  kind  ft  — >  ft',  then  the  term  representation  of  r  is 
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|fi|  =  T  |/t  — *  k'\  =  |/t|  — >  \k!\ 

|x|=  X  |Vx-«|  =  Vx-  (x  -*■  O)  -*•  N 

Figure  8:  Translation  of  Af +  kinds  to  Af  kinds 


a  polymorphic  function  from  representations  to  representations: 

R*-,K'  t  =  W/3:k.  Rk  (3  — ►  R, K>  (r  (3) 

However  a  problem  arises  if  r  is  of  a  variable  kind  x-  The  only 
way  of  knowing  the  type  of  its  representation  Rx  is  to  construct 
it  when  x  is  instantiated.  Hence  programs  translated  into  Af 
must  be  such  that  for  every  kind  variable  x  in  the  program,  a 
corresponding  type  variable  ax,  representing  the  type  of  the  term 
representation  for  a  tag  of  kind  x,  is  also  available. 

In  comparison,  the  source  language  of  CWM  [3]  does  not  in¬ 
clude  kind  polymorphism,  which  means  that  the  types  of  all  rep¬ 
resentations  are  known  statically.  We  need  to  extend  the  frame¬ 
work  with  types  of  representations  of  variable  kinds. 

Consider  for  instance  the  type  V  [k]  r  in  Af +.  The  V  branch 
of  a  typecase  construct  must  reduce  to  an  abstraction  A  x-  Aa  : 
X  —*  f2.  e.  After  translation  to  Af ,  in  order  to  compute  the  type 
of  the  representation  of  a  in  e,  we  need  to  know  the  type  of  the 
representations  of  types  of  kind  x-  Therefore  this  type  must  be 
passed  as  an  extra  argument  to  the  V  branch,  which  means  it 
must  be  “packed”  together  with  k  and  r  using  the  translated  V 
constructor.  Thus,  if  mapped  to  a  constructor  for  kind  12  in  Af , 
its  kind  would  be  Vx-  (x  ~ ^  ~ >  (X  ~ >  ~ adding  a 

parameter  of  kind  x  — >  12  associated  with  the  kind  variable  A 
similar  situation  arises  with  V ,  only  this  time  with  an  unpleasant 
twist:  The  kind  of  the  translated  constructor  must  be  (Vx-  (x  ~ > 
12)  — >  12)  — >  12,  in  which  there  is  a  double-negative  occurrence 
of  12,  making  12  non-inductive. 

To  preserve  the  inductive  structure  of  the  kinds,  we  split  the 
type  calculus  into  types  and  tags.  The  new  constructor  T  +  is 
of  kind  (Vx-  (x  — >  fi)  — >  T)  — >  T,  which  does  not  suffer 
from  negative  occurrences  since  12  is  defined  independently  of 
T.  Type  analysis  is  restricted  to  tags  since  they  carry  the  infor¬ 
mation  needed  to  reconstruct  the  types  of  representations. 

This  leads  us  to  the  kind  translation  from  Af +  to  Af  (Fig¬ 
ure  8).  Since  the  analysis  in  Af  is  on  kind  T,  the  Af +  kind  12 
is  mapped  to  T.  The  polymorphic  kind  Vx-  k  is  translated  to 
Vx-  (x  — 1^1-  Note  that  every  kind  variable  x  must  now 
have  a  corresponding  type  variable  ax  of  kind  \  — >  12,  providing 
the  type  of  term  representations  for  types  of  kind 

Lemma  4.1  |k{«'/x}|  =  M{|«'l/x} 

Proof  By  induction  over  the  structure  of  ft.  □ 

Figure  9  shows  the  function  RK.  Suppose  r  is  a  Af+  type  of 
kind  ft  and  |r|  is  its  translation  into  Af .  The  function  RK  gives 
the  type  of  the  term  representation  of  |r|.  Since  this  function  is 
used  by  the  translation  from  Af +  to  Af ,  it  is  defined  by  induction 
on  Af  +  kinds. 


f  FA  f;Ahtty  :  x-*S! 

£ ;  A  h  f?o  =  R  \  T  — >  12  f;Ah  Rx  =  ax  :  x  ~ 12 
£;  A  h  RK  =  t  :  |ft|  — >  O  £ ;  A  H  RK>  =  r'  :  |ft'|  12 

f;Ah  Rk^k,  =  \a :  |ft  — >  ft'  | .  V/3 :  |ft| .  r  f3  — >  t'  (a  0) 

:  |  ft  — s-  At7 1  — >  L2 

£ ,  X;  A,  ax  :x  — ^ F  RK  =  r  :  |/t|  — >  Q. 

£ ;  A  I-  R\/x.  K  =  Xa :  |Vx-  k\ .  V+x.  Vax  :  x  ->  r  (a  [x]  ax) 

:  |Vx-ft|  ->  n 

Figure  9:  Types  of  representations  at  higher  kinds 


Lemma  4.2  (J?K){|ft'|,i?K//x',ax'}  = 

Proof  By  induction  over  the  structure  of  ft.  □ 

The  formation  rules  for  tags  are  displayed  in  Figure  10.  Since 
the  translation  maps  Af +  type  constructors  to  these  tags,  a  type 
constructor  of  kind  ft  is  mapped  to  a  corresponding  tag  of  kind 
|  ft| .  Thus,  while  the  V  type  constructor  has  the  kind  Vx-  (x  ~ > 
12)  — >  12.  the  Tv  tag  has  the  kind  Vx-  (x  ~ >  ~ >  (X  ~ >  T)  — » 

T. 

Figure  10  also  shows  the  type  of  the  term  representation 
of  the  primitive  type  constructors.  These  types  agree  with  the 
definition  of  the  function  RK\  for  example,  the  type  of  is 
(T_).  The  term  formation  rules  in  Figure  10  use  a 
tag  interpretation  function  F  that  is  explained  in  Section  4.4. 

4.3  Tag  analysis  in  Af 

We  now  consider  the  tag  analysis  constructs  in  more  detail. 
The  term  level  analysis  is  done  by  the  repcase  construct.  Fig¬ 
ures  10  and  11  show  its  static  and  dynamic  semantics  respec¬ 
tively.  The  expression  being  analyzed  must  be  of  type  R  r;  there¬ 
fore,  repcase  always  analyzes  term  representation  of  tags.  Oper¬ 
ationally,  it  selects  a  branch  according  to  the  top  constructor  of 
the  representation,  and  passes  the  components  of  the  representa¬ 
tion  to  it. 

Type  level  analysis  is  performed  by  the  Tagrec  construct. 
The  language  must  be  fully  reflexive,  so  Tagrec  includes  an  ad¬ 
ditional  branch  for  the  new  type  constructor  TR .  Since  only  the 
kind  of  Tm  contains  the  kind  T  in  a  doubly-negative  position 
(Figure  10),  we  can  define  Tagrec  as  an  iterator  over  the  kind 
T,  and  treat  Tf  specially  (like  the  p  constructor  in  Af +). 

Figure  12  shows  the  reduction  rules  for  the  Tagrec.  which  are 
similar  to  the  reduction  rules  for  the  source  language  Typerec: 
given  a  tag,  it  recurses  on  the  components  of  the  tag  and  then 
passes  the  result  of  the  recursive  calls,  along  with  the  original 
components,  to  the  corresponding  branch.  Recursive  tags  are 
handled  in  a  manner  similar  to  recursive  types  in  Af+.  The  re¬ 
sult  is  constrained  to  be  a  recursive  tag.  The  analysis  proceeds 
directly  to  the  body  of  the  tag  function,  with  the  bound  variable 
protected  under  a  Tpi  tag,  which  is  the  right  inverse  of  Tagrec. 

The  reduction  rules  also  include  a  rule  for  the  PI  constructor. 
The  PI  constructor  is  used  to  handle  recursive  tags  in  the  F  func- 
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Type  formation  f;Ah  r  :  k 


£  h  A 


£':  A  r  R  :  T->  Q 

£-AhP\  :  n  ->  T 

f;Ah  Tint  :  T 

f;Ah^  :  T  — >  T  — >  T 

f;  A  h  Tv  :  VX.  (x  -  «)  -  (X  -  T)  -  T 

£;AbT^  :  (VX-  (x  T)  ->  T 

T;AFTM  :  (T  — >  T)  — >  T 

f;AhTpl  :  T  — >  T 

£;A ¥Tr  :  T  — >  T 

£\  A  hr  :  T 
f ;  A  I—  rim  :  T 

f;Ahr_  :  T— tT^T^T— >T 
f;  A  h  TV  :  Vx.  (x  -  n)  -  (x  -  T)  -  (x  -  T)  -  T 
A  h  v  :  (VX.  (X  -  fi)  -  T)  ->  (VX.  (x  ->  n)  -  T)  ->  t 
f;Ahra  :  T  — >  T  — >  T 


<1 

do 

Tagrec  r  of 

x Tint  j  T — ► 

TV)  T^f,  Tfi)  .  T 

Term  formation  £;A;F 

-  e  :  r 

£ 

;  A  F  T 

£ 

;  A;  T  1-  Rint 

R  Tint 

£ 

;  A;  r  h  R^ 

(T_) 

£ 

;  A;  r  h  Rv 

T?vx.  (x 

(Tv) 

£ 

;  A;  r  h  Rv+ 

T(Vx.n)^n  (T  +) 

;  A;r  h  R„ 

Tn_,n 

(Tr) 

£ 

;  A;  r  h  Rp 

(Tp) 

£ 

;  A;  r  h  Rp; 

Tn_,  n 

(Tpi) 

£;  A  h 

t  :  T  -v  T 

T;  A; 

-he:  F(t(T„t)) 

f ;  A;  r  h  fold[r]  e 

LL 

£\  A 

-  r  :  T  -v  T 

<1 

do 

LL 

_L 

£ ;  A;  F  P  unfold[r]  e  : 

F(r(TMr)) 

£■  A  P  r  :  T  -v  fi 

£;A;FI-e 

Rt' 

£ ;  A;  F  F  eint 

T  Tint 

£;  A;F  F  e^ 

Vai : T.  Rot i  — »  \/ot2 

:  T.  R  a2  — >  r  (T_^  ai  a2) 

£ ;  A;  F  F  ev 

v  X-Vax:x 

->  n. 

Va:x  -► 

T.  T?x^n  (a)  ->  r  (Tv  [x]  «) 

£\  A;F  F  e^. 

Va:VX.  (X  FI)  -> 

T.  Tvx.  n  (a)  — >  r  (TA  a) 

£\  A;F  F  eR 

Va:T.  Ra  — >  r  (T„ 

a) 

£ ;  A;  F  F  ep 

Va:T  — >  T. 

a)  -*■  t  {Tp  a) 

£ ;  A;  F  F  epi 

Va :  T.  R a  — >  r  (Tp( 

a) 

£ ;  A;  F  F  repcasefr]  e  of  (ei 

t?  6 CR’i 

Figure  10: 

Foimation  rules  for  the 

new  constructs  in  Af 

repcase[r]  Rint  of  (eint,  e — ev,  er^,  ep,  epi)  eint 

repcase[r]  [n]  (ei)  [r2]  (e2)  of 

(eint;  e^;  ev;  e^;  e#;  eM;  ep;)  e^  [n]  (ei)  [t2]  (e2) 

repcase[r]  Rv  [k]+  [tk]  [r']  (e')  of 

(eint;  e^;  ev;  e^;  eR\  eM;  epi)  ev  [k]  [t«]  [r']  (e') 

repcase[r]  R^f  [r']  (e')  of  (eint ;  e^;  ev;  e^;  efl;  ep;  epi) 
V  [r']  (e') 

repcase[r]  Rfl  [r']  (e')  of  (eint;  e^;  ev;  e^;  eR\  eM;  epi) 
eR  [r']  (e') 

repcase[r]  Rft  [r']  e'  of  (eint;  e^;  ev;  e^t-;  e«;  ep;  epi) 
e,  [r']  (e') 

repcase[r]  Rp;  [r']  (e')  of  (eint;  e^;  ev;  ev+;  e«;  eM;  epi) 
[r']  (e') 

Figure  1 1 :  Selected  term  reduction  rules  of  Af 


tion  (Section  4.4).  This  constructor  is  again  an  implementation 
artifact  in  Af  and  has  no  counterpart  in  the  source  language.  Its 
reduction  rule  will  never  be  used  in  a  program  translated  from 

Af+ 

4.4  The  tag  interpretation  function 

Programs  in  Af  pass  tags  at  runtime  since  only  tags  can  be  ana¬ 
lyzed.  However,  abstractions  and  the  fixpoint  operator  must  still 
carry  type  information  for  type  checking.  Therefore,  these  anno¬ 
tations  must  be  defined  using  a  function  mapping  tags  to  types. 
Since  these  annotations  are  always  of  kind  O,  this  function  must 
be  of  kind  T  — >  Q.  We  can  use  an  iterator  over  tags  to  define  the 
function  as  follows: 

F  (Tint)  =  int 

F(7Vtit2)  =  F  (n)  — +  F  (r2) 

F  {Tw[x]axr)  =  Va:X-  ax  a  ->  F  (r  a) 

F(Tv+t)  =  Vx.Vax:x->  0- F  (r  [x]  <*x) 

F  (Tpt)  =  p(Aq : n.  F  (t  (PI  a))) 

F (PI r)  =  r 

F  {Trt)  =  int 

F  ( Tpi  t )  =  int 

The  function  F  takes  a  type  of  kind  T  and  converts  it  to  the  cor¬ 
responding  type  of  kind  Q.  The  branches  for  the  TR  and  the  Tpi 
tags  are  bogus  but  of  the  correct  kind.  The  language  Af  is  only 
intended  as  a  target  for  translation  from  Af + — the  only  inter¬ 
esting  programs  in  Af  are  the  ones  translated  from  Af+;  there¬ 
fore,  the  Tr  branch  of  F  will  remain  unused.  Similarly,  since  the 
source  language  hides  the  Place  constructor  completely  from  the 
programmer,  it  does  not  appear  in  Af +  programs;  hence  the  Tpi 
branch  of  F  will  also  remain  unused. 

The  type  interpretation  function  has  the  following  properties. 
Lemma  4.3  (F  (r)){r'/a}  =  F  (r{r'/o}) 


£;  A  b  TagrecTint  of  (rint;  r_;  rv;  r^f;  rH)  :  T 
£ ;  A  b  Tagrec  7int  of  (rint;  7v;  r^;  rH)  Tint  :  T 

£ ;  A  b  Tagrec  n  of  (-rint;  r_>;  tv;  t^v;  th)  t(  :  T 
£ ;  A  b  Tagrec  t2  of  (Tint;  T-> ;  tv;  t^;  rH)  r2  :  T 

f;Ab  Tagrec  (TU  ti  t2)  of  (Tint;  T->;  tv;  t^;  rH) 

T— >  Ti  t2  t(  t2  :  T 

£;A,a:n'  b  Tagrec  (t2  a)  of  (Tint;  t_>;  tv;  t^;  tr) 
t'  :  T 

£;  A  b  Tagrec  (Tv  [«']  n  t2)  of  (-rint;  t_;  tv;  t^;  tr) 
tv  M]  ti  t2  (Aa:«/.  t')  :  T 

£,Xi  A,ax:x  ->  0  :b 

Tagrec  (t  [x]  ax)  of  (Ti„t;  t^;  tv;  t^;  tr)  t'  :  T 

£;  A  b  Tagrec  (T^  t)  of  (Tint;  r_>;  tv;  ;  rB) 

V  t(Ax-  Aax:x  ->  n.r')  :  T 

f;Ab  Tagrec  t  of  (Tint;  t_;  tv;  tv+;  tr)  t'  :  T 

£;  A  b  Tagrec  (Tfr)  of  (Tint;  t^;  tv;  t^;  tb) 

TjTT  :  T 

£;  A,a:T  b 

Tagrec  (t  ( Tpi  a))  of  (Tint;  t_>;  tv;  tv+;  th)  t'  :  T 

f ;  A  b  Tagrec  (Tf  t)  of  (Tint;  t— ;  tv;  t^;  tb) 

Tf  (Aa:T.  t')  :  T 

f;Ab  Tagrec  (Tp!  t)  of  (Tint;  t^;  tv;  Ty+;  tb)  :  T 
£ ;  A  b  Tagrec  (Tpi  t)  of  (Tint;  r— ;  tv;  Tyf ;  th)  t  :  T 

f;Ab  Tagrec  (PI  t)  of  (Tint;  t_>;  rv;  rv+;  rB)  :  T 
£;  A  b  Tagrec  (Plr)  of  (Tint;  r_^;  rv;  r^;  rB)  PI  r  :  T 


Figure  12:  Reduction  rules  for  Af  Typerec 


Proof  Follows  from  the  fact  that  none  of  the  branches  of  F  has 
free  type  variables.  □ 

Lemma  4.4  (F  (t)){k/x}  =  F  (t{k/x}) 

Proof  Follows  from  the  fact  that  none  of  the  branches  of  F  has 
free  kind  variables.  □ 

The  language  Af  has  the  following  properties. 

Proposition  4.5  (Type  Reduction)  Reduction  of  well  formed 
types  is  strongly  normalizing  and  confluent. 

Proposition  4.6  (Type  Safety)  If  b  e :  t,  then  either  e  is  a  value, 
or  there  exists  a  term  e!  such  that  e^e1  and  b  e' :  r. 

Note  that  the  rules  for  fold  and  unfold  in  Figure  10  unfold  a 
recursive  type  (of  kind  T)  under  the  tag  interpretation  function. 
If  we  allowed  a  Typerec.  and  therefore  a  Tagrec,  to  have  user- 
defined  result  for  the  analysis  of  recursive  types,  this  would  have 


a  1 

=  a 

int| 

=  Tnt 

|Ax-t| 

=  Ax- A ax:\ 

-1 

=  T_ 

Ml 

=  M  MRk 

|V| 

=  Tv 

A a:n.  t | 

=  Aa:  |«|.  |r| 

ivl 

II 

T  t'\ 

=  M  Ml 

=  7f 

|  Placej 

=  Tpi 

Typerec  r  of  (nnt;  r_>;  tv;  t^)!  = 

Tagrec  |r|  of(|rint|;  |r_>|;  |rv|;  |rv+|;  A_: T.  A_: T.  |rint|) 

Figure  13:  Translation  of  Af +  types  to  Af  tags 


allowed  one  to  write  type  functions  like 

r  =  Xa :  T.  Tagrec  a  of  (. . . ;  T ^  =>■  Tint) 

with  the  property  that  F  (r  ( T f  r))  =  int,  but  F  (Tf  t)  =  p  (Aq  : 
Q.  a),  breaking  the  type  safety  theorem. 

5  Translation  from  Af +  to  Af 

In  this  section,  we  show  a  translation  from  Af +  to  Af .  The  lan¬ 
guages  differ  mainly  in  two  ways.  First,  the  type  calculus  in  Af 
is  split  into  tags  and  types,  with  types  used  solely  for  type  check¬ 
ing  and  tags  used  for  analysis.  Therefore,  type  passing  in  Af + 
will  get  converted  into  tag  passing  in  Af .  Second,  the  typecase 
operator  in  Af +  must  be  converted  into  a  repcase  operating  on 
term  representation  of  tags. 

Figure  13  shows  the  translation  of  Af +  types  into  Af  tags. 
The  primitive  type  constructors  get  translated  into  the  corre¬ 
sponding  tag  constructors.  The  Typerec  gets  converted  into  a 
Tagrec.  The  translation  inserts  an  arbitrarily  chosen  well-kinded 
result  into  the  branch  for  the  TR  tag  since  the  source  contains  no 
such  branch. 

The  term  translation  is  shown  in  Figure  14.  The  translation 
must  maintain  two  invariants.  First,  for  every  kind  variable  x  in 
scope,  it  adds  a  corresponding  type  variable  ax\  this  variable 
gives  the  type  of  the  term  representation  for  a  tag  of  kind  x- 
At  every  kind  application,  the  translation  uses  the  function  RK 
(Figure  9)  to  compute  this  type.  Thus,  the  translations  of  kind 
abstractions  and  kind  applications  are 

|A+x.  v\  =  A+x-  Aax  :x  ->  \v\  \e  [k]+|  =  |e|  [\k\]+  [Rk\ 

Second,  for  every  type  variable  a  in  scope,  a  term  variable  xa  is 
introduced,  providing  the  corresponding  term  representation  of 
a.  At  every  type  application,  the  translation  uses  the  function 
5R(t)  (Figure  15)  to  construct  this  representation.  Furthermore, 
type  application  gets  replaced  by  an  application  to  a  tag,  and  to 
the  term  representation  of  the  tag.  Thus  the  translations  for  type 
abstractions  and  type  applications  are 

|Aa:/c.  v\  =  Aa:  |/t|.  Xxa  :RKa.\v\  \e  [r]|  =  \e\  [|r|]  SR(t) 

As  pointed  out  before,  the  translations  of  abstraction  and  the 
fixpoint  operator  use  the  tag  interpretation  function  F  to  map  tags 
to  types. 
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|A+X.v 
|e[K]+ 
|Aa :  k.  v 
|e[r] 
A x:t.  e 


=  A  x- Aax:x  -►  fi-  M 

=  |e|[|«|f[i?«] 

=  Aa:  |k|.  Xxa  -Rk  a .  |w| 
=  |e|[|r|]SR(r) 

=  A*:  F  1-7-1 .  lei 


|fix*:r.  v|  =  fix*:  F  |r|.  |v| 

|fold[r]  e|  =  fold[|rj]  |e 
|unfold[r]  e|  =  unfold[jr|]  |e| 

|typecase[r]  t'  of  (eint;  e^;  ev;  ey+;  eM)| 

=  repcase[Aa :  T.  F  (|r|  a)]  5R(r/)  of 
Rint  -4*  |  eint  | 

R-  =>  le — ►  I 

Rv  =4-  |ev 

Rv+  ^  I  ev+ 1 

Rh  =4-  A/3:T.  \x:R/3.  fix*:  F  (|r|  (TR  (3)).  x 
R/j  =4  |  e/2 1 

Rpi  =4>  A/3:T.  A x:R  /3.  fix*:  F  (|r|  (Tpi  /?)).* 


Figure  14:  Translation  of  A^+  terms  to  A^  terms 


We  show  the  term  representation  of  types  in  Figure  15.  The 
primitive  type  constructors  get  translated  to  the  corresponding 
term  representation.  The  representations  of  type  and  kind  func¬ 
tions  are  similar  to  the  term  translation  of  type  and  kind  abstrac¬ 
tions.  The  only  involved  case  is  the  term  representation  of  a 
Typerec.  Since  Typerec  is  recursive,  we  use  a  combination  of 
a  repcase  and  a  fix.  We  will  illustrate  only  one  case  here;  the 
other  cases  can  be  reasoned  about  similarly. 

Consider  the  reduction  of  Ty  (r'  — >  t"),  where  Ty  r  stands 
for  Typerec  r  of  (-Tint;  t_>;  tv;  r^f).  This  type  reduces  to 
r_>  t' t"  (Ty  (t'))  (Ty  (*”)) .  Therefore,  in  the  translation,  the 
term  representation  of  r->  must  be  applied  to  the  term  repre¬ 
sentations  of  t',  t",  and  the  result  of  the  recursive  calls  to  the 
Typerec.  The  representations  of  r'  and  t"  are  bound  to  the  vari¬ 
ables  *Q  and  xp\  by  assumption  the  representations  for  the  re¬ 
sults  of  the  recursive  calls  are  obtained  from  the  recursive  calls 
to  the  function  f. 

In  the  following  propositions  the  original  Af +  kind  environ¬ 
ment  A  is  extended  with  a  kind  environment  A(£ )  which  binds 
a  type  variable  ax  of  kind  x  ~ >  FI  for  each  x  £  £ ■  Similarly 
the  term-level  translations  extend  the  type  environment  T  with 
T(A),  binding  a  variable  xa  of  type  RK  a  for  each  type  variable 
a  bound  in  A  with  kind  k. 

Proposition  5.1  If  8\  A  b  r  :  k  holds  in  Af+,  then 
\£ |;  |A|,  A(£ )  h  |t|  :  |/t|  holds  in  Xr. 

Proof  Follows  directly  by  induction  over  the  structure  of  r.  □ 

Proposition  5.2  If£;A\-r  :  k  and  f;A  h  T  hold  in  A^+, 
then  |£|;  |A|,  A(£);  |T|,  T(A)  h  5R(r)  :  RK  |r|  holds  in  Ag. 


SR(int)  =  Rint 

5R(— »)  =  Aa :  T.  A*a  :  R  a.  A/3 :  T.  Xxp  :R(3. 

R^  [a]  (*a)  [/3]  {xp) 

SR(V)  =  A+x-  Aax  :  x  — >  fi-  Aa :  x  — >  T.  Xxa  :  Rx—n  (a). 

RV  M  K]  M  {Xa) 

K(V+)  =  Aa :  (VX.  (x  ->  fi)  -»  T).  A*Q  :  J?vx.  n  (a). 

Ryt  [a]  (*«) 

5R(p)  =  Aa:T  — >  T.  Xax:Rn->n  (a).  RM  [a]  (*a) 
SR(Place)  =  Aa :  T.  Xxa  :  R  a.  Rp;  [a]  (xa) 

5R(a)  =  xa 

5R(Ax-  r)  =  A+x-  Aax  :  x  — >  fi-  Sft(r) 

5R(rM)  =  K(r)  [\k\]+ [RK] 

SR(Aa  :k.t)  =  A  a :  |k|  .  A*a  :  RK  a.  Sft(r) 

»(tt')  =  S(t)  [|t'|]  (5R(t')) 

SR(Typerec  r  of  (rint;  r_;  rv;  r^))  = 

(fixf :  Va :  T.  R  a  — >  R  (r*  a). 

Aa:T.  A xa:Ra. 
repcase[Aa :  T.  R  (r*  a)]  *a  of 
Rint  =4  /ft(Tint) 

R_*  =4  Aa:T.  Xxa  :  Ra.  A/3:T.  Xxp  :R/3. 

SR(r^)  [a]  (xa)  [/3\  (xp) 

[r*  a]  (f  [a]  xa)  [ r *  f3\  (f  [/3]  xp) 

Rv  =4-  A  x-  Aax  :x  — ♦  fi.  Aa:x  — >  T.  Xxa\Rx^n  (a). 

SR(tv)  \xtlax\  N  (*«)  [A/3 :x-t*  (a/3)] 

( A/3 :  x-  Xxp  :axl 3.  f  [a  /3]  (*a  [/3]  *^ ) ) 

Ryt  =4>  Aa: (Vx-  (x  — ►  fi)  -+  T).  Xxa-.R\jx.n  (a). 

®(V)  H  AqA  -X  -*•  fi-  v*  (a  [x]  ax)] 

(A+X-  Aax : X  fi-  f  [a  M  %]  (*«  [x]+  [«xD) 

Rh  =4  Aa:T.  A*a  :3?  a.  5R(rint) 

Rm  =4  Aa:T  — *•  T.  A*a  (a). 

Rp  [A/3: T .  t*  (a  (Tpi  /3))[ 

(A/3:T.  Xxp  :R/3. 

f  [a  (Tpi  /3)]  (*a  [Tpi  /3]  (Rpi  [/3]  (xp)))) 

Rpi  =4-  Aa:T.  Xxa\Ra.  xa) 

[|r|  ] 

5R(r) 

where 

t*  =  | Aa :  Typerec  a  of  (Tint;  rv;  T^f)! 

Figure  15:  Representation  of  Xf+  types  as  XR  terms 


Proof  By  induction  over  the  structure  of  r.  The  only  inter¬ 
esting  case  is  that  of  a  kind  application  which  uses  Lemma  4.2. 

□ 

Proposition  5.3  If  f;A;T  h  e  :  t  holds  in  Af+,  then 
|£|;  |A|,  A(f);  |T|,  T(A)  h  |e|  :  F  |r|  holds  in  Ag. 

Proof  This  is  proved  by  induction  over  the  structure  of  e,  using 
Lemmas  4.3  and  4.4.  □ 
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( values )  v  ::=  i  \  Xx.e  \  fixx.v  |  fold  v 
Rint  I  R^  |  R—  1  |  R^  1  v 
R^  1  v  1  |  R^  1  v  1  v' 

Rv  |  Rvl  |  Rvll  |  Rvlll 
Rvlllu 

Ryf  |  Rvfl  |  Ryflv 
Rm  I  Rm1  |  R„lt> 

RPi  |  RPf  1  |  RPi  1  v 
R«  I  Rr  1  1  Ri?  1  v 

(terms)  e  ::=  v  \  x  \  ee!  |  fold  e  |  unfold  e 

repcase  e  of  (cint;  e — >,  ev,  c^-f,  eRj  e^,  epi) 

Figure  16:  Syntax  of  the  untyped  language  Af^° 


i°  —  i 

(A+x-  v)  =  \-v° 

(A  a:K.v)°  =  A_.v° 

(A x:t.  e)°  =  Aat.e° 
(fix*:r.  u)°  =  fix®.?;0 

(fold[r]  e)°  =  fold  e° 
(unfold[r]  e)°  =  unfold  e° 

(e  M+)°  —  e°  1 

(e[r])°=e°l 
(eei)°  =  e°  ei° 

Rint  —  Rint 

R^°  =  R_ 

(R->  M)°  =  R- 1 

(R_  [r]  e)°  =  R_  1  e° 
(R^  [r]e[r'])°  =  R_le°l 
(R-»  [r]e[r']ei)°  = 


Rv° 

(Rv  mV 

(Rv  M+M)° 
(Rv  M+[r]  [r'])° 
(RvM+M  M  c)° 

R\A  ° 

( v  M)° 
(VM  e)° 
R,° 
(rm  M)° 
(R,Me)° 
RPi° 
(R Pi  M)° 

(Rp«Wc)° 

rh° 

(R*  W)° 

(RB[r]e)° 


=  Rv 

=  RV1 
=  Rvll 
=  Rv  1 1 1 
=  Rv  1 1 1  e° 

=  R\A 
=  Rv+  1 
=  Ryf  le° 

=  Rm 

=  R„  1 

=  Rp  1  e° 

=  Rpi 

=  R  Pi  1 
=  Rp  1 1  e° 

=  R« 

=  r«i 

~  R«  i  e° 


(repcase[r]  e  of  (eint;  e^;  ev;  ey+;  eR\  eM;  epi))°  = 

or/o  o  o  o  o  o  o \ 

T6pC3S6  6  Ol  (^6int  5  6 j  6 y|-  ]  Cr  ]  C/j,  ]  Cpl  J 


Figure  17:  Translation  of  Ajj  to  Af^° 


6  The  untyped  language 

This  section  shows  that  in  Ajj  types  are  not  necessary  for  com¬ 
putation.  Figure  16  shows  an  untyped  language  Af^  .  We  show  a 
translation  from  XR  to  XR  in  Figure  17.  The  expression  1  is  the 
integer  constant  one. 

The  translation  replaces  type  and  kind  applications  (abstrac¬ 
tions)  by  a  dummy  application  (abstraction),  instead  of  erasing 
them.  In  the  typed  language,  a  type  or  a  kind  can  be  applied  to 
a  fixpoint.  This  results  in  an  unfolding  of  the  fixpoint.  There¬ 
fore.  the  translation  inserts  dummy  applications  to  preserve  this 
unfolding. 

The  untyped  language  has  the  following  property  which 
shows  that  term  reduction  in  Aj^  parallels  term  reduction  in  XR. 


Proposition  6.1  Ife  ei,  then  e°  e\°. 

7  Related  work  and  conclusions 

Our  work  closely  follows  the  framework  proposed  in  Crary  et 
al.  [3].  They  consider  a  language  with  analyzes  over  types  with 
no  binding  structure.  Extending  the  analysis  to  arbitrary  types 
makes  the  translation  much  more  complicated.  The  splitting  of 
the  type  calculus  into  types  and  tags,  and  defining  an  interpre¬ 
tation  function  to  map  between  the  two,  is  related  to  the  ideas 
proposed  by  Crary  and  Weirich  for  the  language  LX  [2],  which 
provides  a  powerful  kind  calculus  and  a  construct  for  primitive 
recursion  over  types.  This  allows  the  user  to  define  new  kinds 
and  recursive  operations  over  types  of  these  kinds. 

This  framework  also  resembles  the  dictionary  passing  style  in 
Haskell  [12].  The  term  representation  of  a  type  may  be  viewed 
as  corresponding  to  the  dictionary  for  that  type  (for  some  class). 
However,  the  authors  consider  dictionary  passing  in  an  untyped 
calculus;  moreover,  they  do  not  consider  the  intensional  analysis 
of  types.  Dubois  et  al.  [4]  also  pass  explicit  type  representations 
in  their  extensional  polymorphism  scheme.  However,  they  do 
not  provide  a  mechanism  for  connecting  a  type  to  its  represen¬ 
tation.  Minamide's  [8]  type-lifting  procedure  is  also  related  to 
our  work.  His  procedure  maintains  interrelated  constraints  be¬ 
tween  type  parameters;  however,  his  language  does  not  support 
intensional  type  analysis. 

Duggan  [5]  proposes  another  framework  for  intensional  type 
analysis.  His  system  allows  for  the  analysis  of  types  at  the  term 
level  only.  It  adds  a  facility  for  defining  type  classes  and  al¬ 
lows  type  analysis  to  be  restricted  to  members  of  such  classes. 
Yang  [15]  presents  some  approaches  to  enable  type-safe  pro¬ 
gramming  of  type-indexed  values  in  ML  which  is  similar  to  term 
level  analysis  of  types.  Aspinall  [1]  studied  a  typed  A-calculus 
with  subtypes  and  singleton  types. 

Necula  [11]  proposed  the  idea  of  a  certifying  compiler  and 
showed  the  construction  of  a  certifying  compiler  for  a  type-safe 
subset  of  C.  Morrisett  et  al.  [10]  showed  that  a  fully  type  pre¬ 
serving  compiler  generating  type  safe  assembly  code  is  a  practi¬ 
cal  basis  for  a  certifying  compiler. 

We  have  presented  a  framework  that  supports  the  analysis 
of  arbitrary  source  language  types;  while  the  handling  of  poly¬ 
morphic  and  existential  types  appears  adequate,  problems  remain 
open  in  the  treatment  of  recursive  types  in  our  source  language. 
The  framework  does  not  rely  on  explicit  type  passing;  instead, 
term  level  representations  of  types  are  passed  at  runtime.  This 
allows  the  use  of  term  level  constructs  to  handle  type  informa¬ 
tion  at  runtime. 
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